A hypothetical conversation
“Hi, Frank.”
“Hi, John.”
“Umm… I don’t mean to pry, but what exactly are you doing up on that ladder with that chainsaw?”
“I’m cutting down this tree, of course!”
“No, you’re stripping all the leaves and twigs off the branches, one at a time.”
“Naturally! I have to cut down the entire tree, you know, not just one part of it. I’m trying to put in a pool for my kids to play in, but there’s not enough room in the yard with this tree standing here.”
“Why not just cut at the trunk, Frank?”
“I just said, John. The trunk’s only one part of the tree. I have to cut it all down!”
“But everything’s attached to the trunk, if you trace it back far enough. Cut down the trunk and the whole thing will come down with it. That way, the pool installers won’t have to wait so long before they can get to work.”
“…nah, that’s crazy talk!”
(Frank, of course, works at Microsoft. He’s the guy who wrote the function that the Windows shell uses when you tell it to delete a large folder containing many files and subfolders. I can think of no other explanation why it works the way it does.)
Alternate flow…
“Wow John, you’re right”… Frank climbs down from his ladder and starts attacking the tree at the base of the trunk…
After a few short moments work, the tree comes down, exactly as John predicted.
Unfortunately, what John had failed to appreciate was that by bringing the tree down all at once, there were some collateral consequences…. the tree fell awkwardly across one corner of the house, destroying the corner walls.
Even had this damage not occured, the fallen tree now filled the entire yard, and was simply too big to be moved as it was. Having cut the tree down, Frank was still left with the job of cutting the twigs and branches off into manageable chunks so that he could tidy the yard up.
Even when he was done (much, much later) he realised there was far more mess left than if he had continued to bring the tree down bit by bit in the first place and turned to ask John to give him a hand clearing up.
But John of course, as is typical with “consultants”, had quietly left the scene of devastation, leaving Frank to clean up the mess resulting from his ill informed advice.
I have to suspect that the people at Microsoft know a little bit more about what is involved in deleting file system trees than those of us who aren’t involved at the implementation level and just see the end result, and make the mistake of thinking that the user friendly “tree-like” visualisation of the system maps directly onto some simple structures underneath it all.
It’s quite a bit more complicated than that, I am sure. 😉
Well, of course the analogy breaks down a bit when you take it too far. I would definitely start bringing a *real* tree down by lopping off branches. But a virtual tree isn’t affected by gravity and doesn’t have anything to fall on. I just find it a little bit ridiculous that hitting– has to tie up my UI for O(N) time, which can take minutes or even hours, instead of O(1) time.
I don’t think this is something that was thought through and analyzed by the people at Microsoft. It feels to me like a holdover from the DOS days, when you weren’t allowed to RMDIR a directory that was not empty. So you ended up manually traversing the directory tree and recursively deleting *.*. Then someone came up with DELTREE, which did all the depth-first traversal and recursive deletes for you.
Then they invented a multitasking GUI, and that whole model breaks down. Yes, obviously the file system still has to process each file, in order to mark the disk space as free, but it should do that in a background thread, out of sight, out of mind, and out of my face. Remove the folder immediately, clear its name from the parent folder’s namespace, and let me get on with other tasks without that dialog box cluttering everything up.
They also invented a much, MUCH more complicated file system. I really don’t think deleting a “tree” in the file system is, or can be, as simple as cutting the trunk out from underneath it.
Apart from anything else there are the security implications (something that people have become MORE concerned about, not less) of leaving everything descending from the trunk merely “orphaned” but not actually deleted.
Plus of course, what if you don’t have PERMISSION to delete something 1, 2 or N levels down in the hierarchy?
Apart from the practical concerns however, I would suggest that your UI isn’t in fact tied up… as you yourself point out … your GUI is multitasking. If you insist on waiting while that one operation finishes before doing anything else then that’s your own choice, not something the GUI enforces on you.
🙂
Actually, I think that permissions are hierarchically inherited, tree-style. If I can delete folder X, I can automatically delete any and all of its subfolders, even in the security-conscious Vista and Win7. Can you think of any times when this doesn’t hold true?
And yes, the UI is tied up if I’m trying to delete a folder and then reuse that folder name. I have to wait for the folder to be gone before recreating it. (And yes, I have had this happen to me. More than once.)
GOMO (Get Over it, Move On)
Every MS windows user on the planet faces the same dilemma, so just accept it for how it is.
Funny reading, but a total moot point.
The performance issues on delete become extreme as the numbers get higher. One poorly designed process I had created 5 million files in an ntfs5 folder on a 4 spindle raid array. It took windows over twenty-four hours to delete that folder. Wish there was something that could be done.
@Mason:
Ah, so you weren’t DELETEing a folder, but wishing to EMPTY it…
How about:
– Rename folder A as B
– Create new folder A
– Delete folder B
Enjoy working with A while B (the old A) get’s deleted.
@Karl:
How long did it take to PUT those 5 million files in that folder ?! Compared to that time I’d bet that 24 hours was nothing in comparison…
“Wah wah why does it take so long to remove all the crap out of my garage… (bleat) (moan) (whinge)…”
🙂
What if a file 20 levels deep has the Read/Only, System and/or Hidden attribute?
So John says, “Frank, it’s a great tree! Don’t destroy it! Why not just move the tree somewhere else?”
Frank agrees this is a cool idea, so they Drag and Drop the tree to the corner of the garden.
The pool gets built, then Frank calls up John, “It’s no good. The leaves keep falling in the pool. I’ll have to cut it down after all.”
John says, “No! I like the tree! Lets just Drag and Drop it over into my back yard.”
So they do this, and to their surprise they find a COPY of the tree appears in John’s yard. The original tree is still in Frank’s yard!
Both John and Frank are puzzled by this, so they call the Garden Center. The guy from MicroHorticulture says, you have to Control the Drag and Drop, then the tree will move.
So they try it and it works! Neither Frank nor John really understand why it was necessary for the Control, but hey, the tree moved so they make a mental not in future to control their drag and drops.
Some weeks later, Frank decides to move a bush away from the pool. He remembers moving the Tree so without thinking he automatically does a Control Drag and Drop.
…and now, to his utter amazement, in his own back yard, he gets a COPY of his bush…?!?
So the guy from MicroHorticulture slowly explains:
“If you are in your own yard, you have to control your drag and drops only if you want a copy. If you want to move, you mustn’t control it. But if you want to move to John’s yard, you have to control your drag and drop. But if you want to give John a copy of the bush and you don’t want to move it, you mustn’t control your drag and drop.”
“Understand now?”
John’s eyes glaze over and decides to give up on gardening and has his yard concreted over.
@Ken Knopfli:
I think you are a little confuses about the modifiers for drag-and-drop: Control will always make a copy, Shift will always do a move, Alt will always create a shortcut.
Off course there is a difference when dragging-and-dropping across “gardens” (filesystems): it’s a move as long as you stay within the same “garden”, but it changes to a copy if you drag-and-drop to a different “garden”.
@Mason: “Actually, I think that permissions are hierarchically inherited, tree-style. If I can delete folder X, I can automatically delete any and all of its subfolders, even in the security-conscious Vista and Win7. Can you think of any times when this doesn’t hold true?”
Permissions are usually inherited, but they don’t have to be. It’s perfectly possible to have a subfolder with entirely different permissions. It’s also possible to deny an administrator access to your private folder (In that case, an administrator can take ownership of the folder and after that change permissions again).
The OS also needs to check if a file is in use, and alert applications that files are being deleted when an application is monitoring a folder for changes.
If the OS would hide the folder and start deleting everything in the background, what happens if one file can’t be deleted for whatever reason? The parent folder should be made visible again, but it’s possible that the user has already made a new folder with the same name!
@Bert: You are right, I’m confused. I am a programmer of 30 year’s experience and I’m confused.
Now try explain this to a secretary that has the edges of her screen full of yellow stickies.
There is no reason default drag and drop behavior should flip when copying/moving to a different drive letter.
@Ken: you got me LOL!
@Mason: it was so much worse with the Directory Tree in Windows 3… 😉